Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Code When You Are Alert

Programming requires precision. If you code when you are inattentive, you are much more likely to introduce new bugs and overlook old ones than if you code when you are alert.

Different people are most alert and productive at different times of the day. For many, early morning, after lunch, and late afternoon can be dangerous times to code.

Figure out when you are not at your peak and do something that is less exacting during those times. Read your email, check newsgroups, fill out expense reports, and write progress reports. Later, when you are wide awake, go back to programming, testing, and debugging. Save the most productive hours of the day for precision tasks like coding and debugging.

I am most alert and creative during the early morning and mid-afternoon. Those are the times when I produce the highest-quality code. Right after lunch is when I am most sluggish, so that is when I try to read my email and perform administrative chores.

If you really need to get some programming done right away but you feel a bit drowsy, take a break. Walk around your building or close your office door and do some calisthenics. Get your blood flowing and then go back to work.

Code in Manageable Pieces

Code and test in intervals long enough to accomplish a single task. For example, design and implement a single subroutine in one sitting. Then take a break and do something else for a little while. Stretch, walk around, and clear your mind. Come back refreshed and ready to concentrate.

Try to perform related tasks together. If you need to write several printing routines, write and test them over a one- or two-day period. Your work will be faster and easier if you can keep shared concepts in mind while you work on them. Even then, break the tasks up into manageable subtasks. If you work continuously on the same code for too many hours, you will lose your edge. Stop, stretch, and start again refreshed. Do not code nonstop until you can barely keep your eyes open.

The computer industry is filled with stories of developers working 18 hours a day for weeks at a time to meet some critical deadline. There are two problems with this strategy. First, these developers have seriously messed up their schedule. There is no excuse for these kinds of hours. Either the developers let the project get away from them or the original schedule was unrealistic.

Second, working such ridiculously long hours increases the chances that developers will introduce bugs into the project. Finding and fixing those bugs will mean wasting more time than they would have if they had worked more carefully.

This does not mean developers must never work extra hours, but continuing the practice for days at a time leads to diminishing returns. Eventually, an additional hour spent programming may produce only 45 minutes of productive work. The rest of the hour is wasted chasing bugs that would not have been otherwise introduced.

Close Your Door

Effective programming and debugging requires deep concentration. You need to ensure that you have large blocks of uninterrupted time during which to work.

Remove as many distractions as you possibly can. Ignore your email. If possible, deactivate it so prompts like bells do not interrupt you when new mail arrives. Close your office door, unplug your phone, and draw the curtains. If you work in a cubicle with no door, face your monitor so you cannot see people walk by. If people still interrupt you constantly, hang up a “Do Not Disturb” sign.

Once others realize that you do not want to be bothered when your door is closed or when you are hunched over your terminal, they will probably respect your need for quiet.

If all else fails, hide. While working on one project, I was interrupted so frequently that I started spending three hours each day working on a terminal in a training room on the other side of the building. My most productive hours tend to be early in the morning, so on another project I came to work at 6:00 a.m. I usually got two or three hours of continuous work done before the interruptions began.

Near the end of several of the projects I worked on, the customers became increasingly intrusive. They wanted to be kept informed at all times so they started calling the project members more and more frequently. They requested weekly and even daily status reports. Eventually, the project leader told them to contact only him and that he would only answer email and return phone calls after 3:00 p.m. That gave all of the developers more uninterrupted time to do productive work. It also filtered the customers’ calls. They no longer called unless they really thought it was important. They managed to answer many of their own questions when they tried.

Self-Test

Because this chapter deals with work habits rather than specific coding techniques, this section does not contain sample code. However, there is still an important exercise you can use to review the ideas discussed in this chapter.

First, get a notebook. Write down everything you do in a typical day. If you are not sure where your time goes, keep the notebook with you for a few days and take notes.

Next, identify the parts of the day during which you are alert and productive and those when you are not. Then match the tasks you perform each day to the time periods that are most appropriate. Consolidate tasks if you can. For example, if you read electronic mail a dozen times a day, group these sessions together and read your mail in one or two longer sessions.

Put tasks that require precision and attention to detail in your most-alert time slots. Put less-demanding tasks in less-productive slots. Follow the new schedule for a few days and see if you can improve your productivity. Appendix A, “Self-Test Solutions,” describes the results I achieved when I tried this experiment.

Summary

The Bug Stoppers that follow summarize the key bug-preventing work habits described in this chapter. Some of these practices may seem awkward at first, but once you get used to them they become second nature. A few, like keeping a notebook, take a little extra work but can occasionally save you a tremendous amount of time. Others, like leaving working code alone, can save work now and prevent bugs that you will need to fix in the future.

	BUG STOPPERS: Work Habits
	Keep a notebook.
	Keep a bug log.
	Analyze the bug log.
	Save everything.
	Do it now.
	Fix it now.
	Test it now.
	If it works, don’t fix it.
	Don’t fiddle.
	Design before you code.
	Code when you are alert.
	Code in manageable pieces.
	Close your door.